Мы много писали о возможностях новой версии платформы VMware vSphere 7 (например, тут и тут), но нововведений там столько, что это не уместить и в десять статей. Сегодня мы поговорим об изменениях в структуре разделов (Partition Layout), которые произошли в VMware ESXi 7.

Первое, что надо отметить, что до vSphere 7 разделы были фиксированного объема, а их нумерация была статической, что ограничивало возможности по управлению ими, например, в плане поддержки больших модулей, функций отладки и стороннего ПО.

Поэтому в vSphere 7 были увеличены размеры загрузочных областей, а системные разделы, которые стали расширяемыми, были консолидированы в один большой раздел.

В VMware vSphere 6.x структура разделов выглядела следующим образом:

Как мы видим, размеры разделов были фиксированы, кроме раздела Scratch и опционального VMFS datastore. Они зависят от типа загрузочного диска (boot media) и его емкости.

В VMware vSphere 7 произошла консолидация системных разделов в область ESX-OSData:

Теперь в ESXi 7 есть следующие 4 раздела:

• System boot - хранит boot loader и модули EFI. Формат: FAT16.
• Boot-banks (2 штуки) - системное пространство для хранения загрузочных модулей ESXi. Формат: FAT16.
• ESX-OSData - унифицированное хранилище дополнительных модулей, которые не необходимы для загрузки. К ним относятся средства конфигурации и сохранения состояния, а также системные виртуальные машины. Формат: VMFS-L. Для этой области нужно использовать долговременные хранилища на базе надежных устройств.

Как вы видите, ESX-OSData разделен на две части: ROM-data и RAM-data. Часто записываемые данные, например, логи, трассировка томов VMFS и vSAN EPD, глобальные трассировки, горячие базы данных - хранятся в RAM-data. В области ROM-data хранятся нечасто используемые данные, например, ISO-образы VMware Tools, конфигурации, а также дампы core dumps.

В зависимости от размера устройства, куда устанавливается ESXi, меняется и размер всех областей, кроме system boot:

Если размер устройства больше 128 ГБ, то ESXi 7 автоматически создает VMFS-тома.

Когда вы используете для запуска ESXi устройства USB или карточки SD, то раздел ESX-OSData создается на долговременном хранилище, таком как HDD или SSD. Когда HDD/SSD недоступны, то ESX-OSData будет создан на USB-устройстве, но он будет содержать только ROM-data, при этом RAM-data будет храниться на RAM-диске (и не сохранять состояние при перезагрузках).

Для подсистем ESXi, которым требуется доступ к содержимому разделов, используются символьные ссылки, например, /bootbank и /altbootbank. А по адресу /var/core лежат дампы core dumps:

В VMware vSphere Client можно посмотреть информацию о разделах на вкладке Partition Details:

Ту же самую информацию можно получить и через интерфейс командной строки ESXi (команда vdf):

Обратите внимание, что соответствующие разделы смонтированы в BOOTBANK1 и 2, а также OSDATA-xxx.

Кстати, вы видите, что OSDATA имеет тип файловой системы Virtual Flash File System (VFFS). Когда OSDATA размещается на устройствах SDD или NVMe, тома VMFS-L помечаются как VFSS.

ESXi поддерживает множество устройств USB/SD, локальных дисков HDD/SSD, устройств NVMe, а также загрузку с тома SAN LUN. Чтобы установить ESXi 7 вам нужно выполнить следующие требования:

• Boot media размером минимум 8 ГБ для устройств USB или SD
• 32 ГБ для других типов устройств, таких как жесткие диски, SSD или NVMe
• Boot device не может быть расшарен между хостами ESXi

Если вы используете для установки ESXi такие хранилища, как M.2 или другие не-USB девайсы, учитывайте, что такие устройства могут быстро износиться и выйти из строя, например, если вы используете хранилища VMFS на этих устройствах. Поэтому удалите тома VMFS с таких устройств, если они были созданы установщиком по умолчанию.

Мы много писали о новых возможностях платформы VMware vSphere 7, но невозможно рассказать обо всех ее нововведениях в одной статье. Сегодня мы расскажем об одной интересной штуке - компоненте Watchdog Timer, который мы упоминали в одном предложении в статье о новых фичах.

Теперь для виртуальных машин доступно специальное устройство virtual watchdog timer (vWDT), которое позволяет администраторам в унифицированном виде узнавать о том, что гостевая операционная система и приложения данной ВМ зависли или вывалились в синий экран. Это особенно важно для кластеризованных приложений в целях поддержания их доступности.

В случае если гостевая ОС и приложения зависли, Watchdog позволяет обнаружить это и среагировать определенным образом, например, перезагрузить машину. Для этого есть механизм таймера обратного отчета, который должен сбрасываться в нормальном режиме функционирования системы.

Это виртуальное устройство пробрасывается в гостевую ОС через механизм BIOS/EFI ACPI и настраивается на уровне гостевой системы или самого BIOS/EFI.

Таблица Watchdog Resource Table (WDRT) имеет несколько регистров, в которые можно записать значения таймера, действия по их истечению и другие параметры. Большинство современных ОС поддерживают интеграцию с таблицей Watchdog Action Table (WDAT), определяющей список доступных действий для таймеров, которые и использует компонент WDRT.

Вот список доступных инструкций WDAT:

• WATCHDOG_ACTION_RESET
• WATCHDOG_ACTION_QUERY_CURRENT_COUNTDOWN_PERIOD
• WATCHDOG_ACTION_QUERY_COUNTDOWN_PERIOD
• WATCHDOG_ACTION_SET_COUNTDOWN_PERIOD
• WATCHDOG_ACTION_QUERY_RUNNING_STATE
• WATCHDOG_ACTION_SET_RUNNING_STATE
• WATCHDOG_ACTION_QUERY_STOPPED_STATE
• WATCHDOG_ACTION_SET_STOPPED_STATE
• WATCHDOG_ACTION_QUERY_REBOOT
• WATCHDOG_ACTION_SET_REBOOT
• WATCHDOG_ACTION_QUERY_SHUTDOWN
• WATCHDOG_ACTION_SET_SHUTDOWN
• WATCHDOG_ACTION_QUERY_WATCHDOG_STATUS
• WATCHDOG_ACTION_SET_WATCHDOG_STATUS

Для большинства современных серверных ОС Windows и Linux не требуется каких-либо действий для дополнительной настройки таймера, но они могут понадобиться для некоторых старых систем, а FreeBSD или Mac OS X вовсе не поддерживают Watchdog Timer. Вот в целом информация о его поддержке:

• Windows 2003 поддерживает Watchdog Resource Table (WDRT)
• Windows 2008 и более поздняя поддерживает Watchdog Action Table (WDAT). Гостевая ОС не требует дополнительной конфигурации.
• Linux-дистрибутивы, такие как Ubuntu 18.04 и Red Hat Enterprise Linux 7.6, на базе ядра 4.9 или более позднего поддерживают Watchdog Action Table (WDAT). Для этого нужен драйвер wdat_wdt.ko.

Для настройки вам понадобится виртуальная машина с VM hardware версии 17 (появилось в vSphere 7). Надо просто добавить устройство Watchdog Timer:

Как вы видите, виртуальный Watchdog Timer можно включить либо на уровне BIOS/EFI (тогда он будет запускаться до старта ОС), либо на уровне гостевой ОС. Помните, что если гостевая ОС не поддерживает это устройство, то машина будет постоянно перезапускаться по команде от устройства Watchdog.

В vSphere Client видна информация о статусе исполнения Watchdog Timer. Не запущен:

Запущен:

На днях компании Dell EMC и VMware (которые как бы одна компания) анонсировали второе поколение программно-аппаратных комплексов VMware Cloud on Dell EMC 2nd Generation. Напомним, что о первом поколении этого решения, анонсированного на VMworld 2019, мы писали вот тут.

Второе поколение сосредоточено на технологиях для датацентров, где требуется высокая производительность приложений при высокой плотности размещения виртуальных машин и контейнеров на хост-серверах.

Теперь к стойке R1 (24 юнита) добавлена еще и полноразмерная стойка R2 на 42 юнита, которая включает в себя зарезервированные коммутаторы, умные розетки PDU и устройства для удаленного управления SD-WAN. В стойку поместится до 16 рабочих узлов (instance nodes):

В стойке R2 нет UPS, так как подразумевается, что сервисы бесперебойного питания предоставляются на уровне датацентра.

Также существенно изменились и спецификации узлов, которых теперь три типа:

Хосты VxRail теперь сделаны на базе второго поколения процессоров Intel SP, предоставляющих до 48 ядер на 2 физических сокета. По памяти максимум - это 768 GB RAM и 23 TB хранилища NVMe all-flash. Все это хорошо подходит под задачи тяжелых баз данных, приложений AI/ML и высоконагруженных виртуальных ПК.

Для резервного копирования сертифицированы 2 решения:

• Dell EMC PowerProtect Cyber Recovery
• Veeam Availability Suite

Также в рамках архитектуры экспериментально поддерживается решение VMware HCX, чтобы создать единую среду между онпремизным датацентром и облачным на основе архитектуры VMware Cloud Foundation (VCF), где работают средства по обеспечению катастрофоустойчивости рабочих нагрузок VMware Site Recovery Manager. С помощью HCX можно смигрировать сотни рабочих нагрузок одновременно из локального датацентра в облачный.

Кроме того, для пользователей теперь доступна возможность увеличения размера узлов, чтобы динамически увеличивать ресурсы при росте нагрузок:

Ранее VMware Cloud Console предоставляла возможности управления гибридной инфраструктурой только для VMware Cloud on AWS SDDC, теперь же это поддерживается и для датацентров VMware Cloud on Dell EMC SDDC:

Больше информации о решении VMware Cloud on Dell EMC можно получить на основной странице продукта.

На сайте проекта VMware Labs появилась еще одна узкоспециализированная, но интересная штука - проект Supernova. С помощью данного интерфейса разработчики решений, использующих машинное обучение (Machine Learning), могут создавать свои проекты на базе различных открытых библиотек с поддержкой технологий аппаратного ускорения графики.

Типа таких:

Проект Supernova поддерживает все самые популярные технологии аппаратного ускорения 3D-графики:

• Nvidia GPU
• Intel IPU/VPU
• Intel FPGA
• Google (Edge) TPU
• Xilinx FGPA, AMD GPU

Для работы Supernova поддерживается ОС Ubuntu или CentOS с контейнерным движком Docker. Сфера применения решения очень широка - распознавание лиц (пол, возраст, эмоции), номерных знаков автомобилей, задача классификации объектов и многое другое.

В качестве тулкитов совместно с Supernova можно использовать следующие:

• OpenVINO
• SynapseAI
• TensorRT
• Tensorflow Lite
• Vitis
• RoCm

Данные для тренировки нейронных сетей могут быть представлены в форматах Tensorflow, Caffe, ONNX и MxNet. Примеры работы с ними представлены в документации, которую можно скачать вместе с пакетом.

Скачать само решение Supernova можно по этой ссылке.

Вильям Лам написал интересную заметку о том, как пробросить USB-клавиатуру или мышь хоста ESXi (они называются USB HID Devices) в гостевую ОС виртуальной машины на VMware vSphere.

Такое может понадобиться, например, когда требуется пробросить в конкретную ВМ отдельную пару USB-устройств ввода (клавиатура+мышь), помимо выделенного устройства vGPU. Также некоторые другие устройства (например, датчики температуры) также притворяются HID-девайсами. Хост ESXi в этом случае по умолчанию не считает необходимым подцеплять такие устройства никуда.

Это поведение можно изменить, добавив следующие параметры в VMX-файл виртуальной машины (или ее Advanced Settings):

usb.generic.allowHID = "TRUE"
usb.quirks.device0 = "X:Y allow"

Вторая вещь, которая вам может понадобиться - это проброс USB-устройств Chip Card Interface Devices (CCID) в виртуальную машину (например, ридер смарт-карт). Для этого в VMX нужно добавить следующие строчки:

usb.generic.allowCCID = "TRUE"
usb.quirks.device0 = "X:Y allow"

В обоих этих случаях X - это vendorId, а Y - deviceId (например, выглядит так - 0x03f0:0x0024).

Чтобы узнать эти параметры, нужно выполнить в консоли ESXi команду lsusb.

После добавления указанных настроек виртуальная машина должна увидеть эти USB-устройства с хоста.

Как вы знаете, обновлением виртуальной инфраструктуры в VMware vSphere 7 вместо Update Manager теперь занимается комплексное средство vSphere Lifecycle Manager (vLCM). vLCM можно использовать для применения установочных образов, отслеживания соответствия (compliance) и приведения кластера к нужному уровню обновлений. 

Одной из возможностей этого средства является функция проверок на совместимость (Compatibility Checks). Они нужны, например, в случаях, когда вы настроили интеграцию Hardware Support Manager (HSM) для серверов Dell или HP и хотите проверить оборудование развертываемого сервера на совместимость с ESXi. Это так называемые Hardware Compatibility Checks.

Во время проверок можно использовать кастомный образ ESXi с дополнениями Firmware и Drivers Addon для проверки образов от поддерживаемых вендоров на совместимость с имеющимся у вас оборудованием и установленной версией микрокода. Вот так в vLCM выглядит проверка соответствия для образов ESXi:

На этом скриншоте видно, что текущий уровень компонентов хоста ESXi не соответствует желаемым параметрам в плане версий Firmware аппаратных компонентов. В этом случае есть опция Remediate (кнопка вверху слева), которая позволяет привести хосты ESXi в соответствие, обновив микрокод аппаратных компонентов средствами Hardware Support Manager - и все это прямо из клиента vSphere Client, без сторонних консолей.

vLCM предоставляет также функции автоматической проверки (HCL Automatic Checks), с помощью которых можно автоматически и систематически искать несоответствия уровня firmware на хостах ESXi и сверять их с актуальной онлайн-базой VMware Compatibility Guide (VCG, он же Hardware Compatibility Guide - HCL).

Если вы зайдете в раздел Cluster > Updates, то увидите результат работы автоматического тестирования на совместимость с необходимыми деталями. Пока это доступно только для контроллеров хранилищ vSAN (storage controllers), что является критически важной точкой виртуальной инфраструктуры с точки зрения обновлений (стабильность, производительность).

На скриншоте ниже показаны результаты проверки совместимости в кластере для адаптера Dell HBA330. В данном случае видно, что на всех хостах установлена одинаковая и последняя версия firmware, что и является правильной конфигурацией:

По ссылке "View in HCL" вы сможете увидеть, что данный адаптер с данной версией микрокода действительно поддерживается со стороны VMware vSphere и vSAN.

При развертывании новой версии платформы VMware vSphere 7 в виртуальной машине (вложенные/nested ESXi) на серверах со старыми процессорами вы можете столкнуться с тем, что ваш CPU не поддерживается со стороны платформы:

CPU_SUPPORT ERROR

Такая ситуация, например, произошла у Rajesh Radhakrishnan на сервере HP 380 G7, где он развертывал виртуальный ESXi 7.0 на платформе vSphere 6.0 Update 3:

В этом случае вы все равно можете установить гипервизор ESXi седьмой версии. Для этого вам надо открыть настройки виртуальной машины:

В разделе CPUID Mask нажать ссылку Advanced и далее вбить в регистре eax для Level 1 следующие значения:

• Для процессоров Intel CPU: 0000:0000:0000:0011:0000:0110:1100:0011
• Для процессоров AMD CPU: 0000:0000:0110:0000:0000:1111:0001:0000

После этого включайте ВМ, где будет установлен ESXi 7, и проходите до конца установки:

После этого ваш ESXi 7 спокойно загрузится. Затем нужно откатить маскирование функций CPU к исходной чистой конфигурации, удалив значение регистра eax:

Обратите внимание, что такая конфигурация не поддерживается в производственной среде! Поэтому используйте такие виртуальные ESXi 7 только для тестирования и других некритичных задач.

Как все уже знают, VMware vSphere 7 вышла, доступна для скачивания и уже обкатывается многими администраторами виртуальных инфраструктур. Для тех, кто еще не знает, поддерживает ли текущее оборудование новый гипервизор ESXi 7, Florian Grehl сделал специальный сценарий PowerCLI, который позволяет вывести эту информацию для серверов кластера:

Сценарий доступен в репозитории на GitHub. Скрипт автоматически загружает функцию HCL-Check (из GitHub), а также JSON-файл для VMware HCL. В переменной $scope можно установить серверы, которые будут проверены (по умолчанию проверяется все окружение vCenter).

Надо понимать, что если ваш хост не поддерживается для VMware ESXi 7, то имеет смысл проверить его еще раз на всякий случай в реальном VMware HCL.

Если вы получаете вот такое сообщение об ошибке:

.\check_esxi_70_support.ps1 : File .\check_esxi_70_support.ps1 cannot be loaded. The file is not digitally signed. You cannot run this script on the current system. For more information about running scripts and setting execution policy, see about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170.

Значит нужно в свойствах скрипта разблокировать его:

Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 7, а также функциональности нового механизма динамического распределения нагрузки VMware DRS 2.0. Среди новых возможностей DRS мы упоминали про функции Assignable Hardware, которые позволяют назначить профили устройств PCIe с поддержкой Dynamic DirectPath I/O или NVIDIA vGPU для первоначального размещения виртуальных машин в кластере.

Сегодня мы поговорим об этой технологии в целом. Ранее виртуальные машины, использовавшие технологии DirectPath I/O или vGPU, привязывались к физическому адресу устройства, который включал в себя адрес расположения устройства на конкретной шине PCIe конкретного хоста ESXi. Это делало невозможным использование такой ВМ на других серверах кластера, что, конечно же, делало невозможным и работу технологий HA и DRS, которые являются критически важными в современных датацентрах.

Таким образом, технология Assignable Hardware позволяет отделить виртуальную машину от конкретного устройства и дать ей возможность быть запущенной на другом хосте ESXi с таким же устройством (или даже другим, но поддерживающим определенный набор функций).

Теперь при настройке виртуальной машины у вас есть выбор одного из следующих вариантов для устройства PCIe:

• DirectPath I/O (legacy-режим, без интеграции с HA и DRS)
• Dynamic DirectPath I/O
• NVIDIA vGPU

После того, как вы выберете нужный профиль оборудования, механизм DRS сможет разместить машину на хосте ESXi с поддержкой нужных функций для ВМ.

На скриншоте выше, во второй опции Select Hardware, также есть лейбл "GPGPU example" - это возможность задать определенным устройствам метки таким образом, чтобы при выборе размещения ВМ использовались только устройства хостов с данными метками (при этом модели устройств могут отличаться, например, NVIDIA T4 GPU и RTX6000 GPU). Либо можно выбрать вариант использования только идентичных устройств.

Назначить метку можно во время конфигурации PCIe-устройств. В гифке ниже показано, как это делается:

При использовании NVIDIA vGPU для виртуальной машины выделяется только часть устройства. Поддержка горячей миграции vMotion для машин, использующих vGPU, уже была анонсирована в VMware vSphere 6.7 Update 1. Теперь эта поддержка была расширена, в том числе для DRS, который теперь учитывает профили vGPU.

Ну и в видео ниже вы можете увидеть обзор технологии Assignable Hardware:

Кластер отказоустойчивых хранилищ VMware vSAN состоит из нескольких хостов ESXi, на локальных хранилищах которых создаются дисковые группы, где размещаются данные виртуальных машин. В процессе создания, перемещения и удаления дисковых объектов ВМ распределение емкости на дисках может изменяться, иногда довольно существенно.

Все это приводит к дисбалансу кластера по дисковой емкости, что создает разную нагрузку на устройства, а это не очень хорошо:

В случае возникновения подобного дисбаланса в кластере VMware vSAN, в консоли vSphere Client на вкладке Monitor, в разделе vSAN Health появляется нотификация vSAN Disk Balance (выполняется эта проверка каждые 30 минут по умолчанию):

Чтобы устранить подобные ситуации, в кластере VMware vSAN есть механизм автоматической балансировки - Automatic Rebalance, который относится к дисковым объектам кластера vSAN, которые распределяются по дисковым группам разных хостов. Если данная настройка включена, то кластер vSAN автоматически наблюдает за балансом распределения дисковых объектов по хостам ESXi и выравнивает нагрузку на дисковые устройства.

По умолчанию пороговое значение составляет 30% (параметр Average Load Varinace - среднее значение разницы между минимальной и максимальной используемой емкостью на дисках в процентах). Это означает, что когда разница нагрузки между двумя дисковыми устройствами достигнет этого значения - начнется автоматическая перебалансировка и перемещение дисковых объектов. Она будет продолжаться, пока это значение не снизится до 15% или меньшей величины.

Также перебалансировка сама запустится, когда диск заполнен на более чем 80%. Надо помнить, что операция эта создает нагрузку на дисковые хранилища, поэтому надо учитывать, что у вас должен быть некоторый запас по производительности, чтобы автоматическая балансировка не съела полезные ресурсы.

В случае если у вас включена настройка Automatic Rebalance, кластер vSAN будет стараться поддерживать этот хэлсчек всегда зеленым. Если же отключена - то в случае возникновения дисбаланса загорится алерт, и администратору нужно будет вручную запустить задачу Rebalance Disks.

Эта опция называется ручной проактивной балансировкой кластера, она становится доступной когда разница в использовании дисковой емкости двух или более дисков начинает превышать 30%:

Если вы запускаете такую балансировку вручную, то продлится она по умолчанию 24 часа и затем сама остановится.

Надо понимать, что операция ребалансировки - это совершенно другая операция, нежели vSAN Resync. Она служит только целям сохранения равномерной нагрузки в кластере с точки зрения дисков.

Также есть возможность контроля операций ребалансировки с помощью интерфейса Ruby vSphere Console (RVC). Для этого вам нужно сменить пространство имен (namespace) на computers и выполнить следующую команду для кластера, чтобы посмотреть информацию о текущем балансе:

vsan.proactive_rebalance_info <номер кластера vSAN или символ "." для текущего пути консоли RVC>

Результат выполнения команды будет, например, таким:

/localhost/Test-DC/computers/Test-CL> vsan.proactive_rebalance_info .

  2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-3.labs.org ...

  2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-1.labs.org ...

  2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-2.labs.org ...

  2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-3.labs.org (may take a moment) ...

  2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-2.labs.org (may take a moment) ...

  2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-1.labs.org (may take a moment) ...

  2019-08-16 19:31:10 +0000: Done fetching vSAN disk infos
  Proactive rebalance start: 2019-08-16 19:30:47 UTC

  Proactive rebalance stop: 2019-08-17 19:30:54 UTC

  Max usage difference triggering rebalancing: 30.00%

  Average disk usage: 56.00%

  Maximum disk usage: 63.00% (17.00% above minimum disk usage)

  Imbalance index: 10.00%

  No disk detected to be rebalanced
 

В этом случае ребалансировка не требуется. Если же вы, все-таки, хотите ее запустить, то делается это следующей командой:

vsan.proactive_rebalance -s <номер кластера vSAN или символ "." для текущего пути консоли RVC>

Вы увидите нечто подобное:

/localhost/Test-DC/computers/Test-CL> vsan.proactive_rebalance . -s

  2019-08-16 19:30:55 +0000: Processing vSAN proactive rebalance on host esxi-3.labs.org ...

  2019-08-16 19:30:55 +0000: Processing vSAN proactive rebalance on host esxi-1.labs.org ...

  2019-08-16 19:30:55 +0000: Processing vSAN proactive rebalance on host esxi-2.labs.org ...
  

В любой момент вы также можете проверить статус ребалансировки в конкретном кластере командой:

vsan.proactive_rebalance_info <номер кластера vSAN>

Ну и вы можете изменить время, в течение которого будет идти ручная ребалансировка. Для этого задайте значение в секундах следующей командой (в данном примере - это 7 дней):

vsan.proactive_rebalance . -t 604800

На днях пришла пара важных новостей о продуктах компании StarWind Software, которая является одним из лидеров в сфере производства программных и программно-аппаратных хранилищ для виртуальной инфраструктуры.

StarWind HCA All-Flash

Первая важная новость - это выпуск программно-аппаратного комплекса StarWind HyperConverged Appliance (HCA) All-Flash, полностью построенного на SSD-накопителях. Обновленные аппаратные конфигурации StarWind HCA, выполненные в форм-факторе 1 или 2 юнита, позволяют добиться максимальной производительности хранилищ в рамках разумной ценовой политики. Да, All-Flash постепенно становится доступен, скоро это смогут себе позволить не только большие и богатые компании.

Решение StarWind HCA - это множество возможностей по созданию высокопроизводительной и отказоустойчивой инфраструктуры хранилищ "все-в-одном" под системы виртуализации VMware vSphere и Microsoft Hyper-V. Вот основные высокоуровневые возможности платформы:

• Поддержка гибридного облака: кластеризация хранилищ и active-active репликация между вашим датацентром и любым публичным облаком, таким как AWS или Azure
• Функции непрерывной (Fault Tolerance) и высокой доступности (High Availability)
• Безопасное резервное копирование виртуальных машин
• Катастрофоустойчивость на уровне площадок
• Максимизация производительности за счет RDMA
• Распределенное кэширование
• Проактивная поддержка вашей инфраструктуры специалистами StarWind
• И многое, многое другое

Сейчас спецификация на программно-аппаратные модули StarWind HCA All-Flash выглядит так:

После развертывания гиперконвергентной платформы StarWind HCA она управляется с помощью единой консоли StarWind Command Center.

Ну и самое главное - программно-аппаратные комплексы StarWind HCA All-Flash полностью на SSD-дисках продаются сегодня, по-сути, по цене гибридных хранилищ (HDD+SSD). Если хотите узнать больше - обращайтесь в StarWind за деталями на специальной странице. Посмотрите также и даташит HCA.

Новый StarWind Virtual SAN V8 для Hyper-V

Второй важный релиз - это обновленная версия продукта StarWind Virtual SAN V8 for Hyper-V (билд 13481 от 25 февраля 2020 года).

Давайте посмотрим, что нового появилось в StarWind Virtual SAN V8 for Hyper-V:

Ядро продукта

• Добавлен мастер для настройки StarWind Log Collector. Теперь можно использовать для этого соответствующее контекстное меню сервера в Management Console. Там можно подготовить архив с логами и скачать их на машину, где запущена Management Console.
• Исправлена ошибка с заголовочным файлом, который брал настройки из конфига, но не существовал на диске, что приводило с падению сервиса.
• Улучшен вывод событий в файлы журнала, когда в системе происходят изменения.
• Улучшена обработка ответов на команды UNMAP/TRIM от аппаратного хранилища.
• Добавлена реализация процессинга заголовка и блога данных дайждестов iSCSI на процессорах с набором команд SSE4.2.
• Максимальное число лог-файлов в ротации увеличено с 5 до 20.

• Процедура полной синхронизации была переработана, чтобы избежать перемещения данных, которые уже есть на хранилище назначения. Делается это путем поблочного сравнения CRC и копирования только отличающихся блоков.
• Исправлена ошибка падения сервиса в случае выхода в офлайн партнерского узла при большой нагрузке на HA-устройство.
• Значение по умолчанию пинга партнерского узла (iScsiPingCmdSendCmdTimeoutInSec) увеличено с 1 до 3 секунд.
• Исправлена ошибка с утечкой памяти для состояния, когда один из узлов был настроен с RDMA и пытался использовать iSER для соединения с партнером, который не принимал соединений iSER.

• Реализована поддержка SMTP-соединений через SSL/STARTTLS.
• Добавлена возможность аутентификации на SMTP.
• Добавлена возможность проверки настроек SMTP путем отправки тестового сообщения.

• Список регионов для всех репликаций помещен во внешний файл JSON, который можно просто обновлять в случае изменений на стороне провайдера.
• Исправлена обработка баркодов с длиной, отличающейся от дефолтной (8 символов).
• Исправлена ошибка падения сервиса при загрузке tape split из большого числа частей (тысячи).
• Исправлены ошибки в настройках CloudReplicator Settings.

• Обновился скрипт AddVirtualTape.ps1, был добавлен учет параметров, чувствительных к регистру.
• Для команды Remove-Device были добавлены опциональные параметры принудительного отсоединения, сохранения сервисных данных и удаления хранимых данных на устройстве.
• Добавлен метод IDevice::EnableCache для включения и отключения кэша (смотрите примеры FlashCache.ps1 и FlushCacheAll.ps1).
• VTLReplicationSettings.ps1 — для назначения репликации используется число, кодирующее его тип.
• Свойство "Valid" добавлено к HA channel.
• Сценарий MaintenanceMode.ps1 — улучшенная обработка булевых параметров при исполнении сценария из командной строки.
• Тип устройства LSFS — удален параметр AutoDefrag (он теперь всегда true).

• Небольшие улучшения и исправления ошибок.

Скачать полнофункциональную пробную версию StarWind Virtual SAN for Hyper-V можно по этой прямой ссылке. Release Notes доступны тут.

Интересная штука появилась на GitHub - проект VMware Community Homelabs от Вильяма Лама, в котором описаны конфигурации и стоимость аппаратных тестовых лабораторий участников комьюнити VMware, которые они строят у себя дома или где-либо еще за свои деньги.

Самая бюджетная (кстати, у Вильяма Лама) лаба стоит 800 долларов, самая дорогая - 150 000 долларов, средняя - 1152 доллара. Вот так выглядит схема домашней лаборатории почти за 10 миллионов рублей:

А вот за 50 тысяч рублей:

Свою домашнюю лабораторию вы можете добавить в список с помощью вот этой странички.

На Reddit коллеги заметили, что при включении технологии Turbo Boost в процессорах Intel, из виртуальной машины увеличения производительности не наблюдается. Напомним, что Turbo Boost — это технология компании Intel для автоматического увеличения тактовой частоты процессора свыше номинальной, если при этом не превышаются ограничения мощности, температуры и тока в составе расчётной мощности (TDP).

При этом емкость CPU показывается прежней, даже при создании существенной нагрузки на процессор:

В комментариях люди правильно отвечают, что поскольку Turbo Boost - это аппаратная возможность, гостевая система виртуальной машины не ловит отображение увеличения аппаратной мощности в виртуальную машину. При этом если вы посмотрите на виртуальную машину с 4 процессорами 2.4 ГГц с уровня хоста ESXi с включенным Turbo Boost до 3 ГГц, вы увидите утилизацию процессора 4*3=12 ГГц.

То есть гостевая система вполне будет использовать преимущества этой технологии, но отображать утилизацию процессора она будет в соответствии с его номинальной мощностью.

Также нужно убедиться, что ваш хост не использует политику питания High performance power management policy, которая отключает Turbo Boost. Вместо этого используйте политику Balanced, которая включена по умолчанию.

На сайте проекта VMware Labs обновился пакет USB Network Native Driver for ESXi до версии 1.4, который содержит в себе драйверы для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.

Давайте посмотрим, что там появилось нового:

• Добавлена поддержка USB-устройств SuperMicro/Insyde Software Corp.
• Исправлена проблема больших кадров 9K Jumbo frames для устройств с чипсетом RTL8153.
• Устранена ошибка с неправильным отображением пропускной способности для некоторых устройств на дефолтной скорости.

Новые номера билдов теперь следующие:

• ESXi670-VMKUSB-NIC-FLING-33242987-offline_bundle-15615590.zip
• ESXi650-VMKUSB-NIC-FLING-33268102-offline_bundle-15620342.zip

Список поддерживаемых устройств на сегодняшний день выглядит так:

Скачать USB Network Native Driver for ESXi версии 1.4 можно по этой ссылке.

Большинство из вас, конечно же, слышало о серии уязвимостей в процессорах Intel (например, Meltdown и Spectre), которые потенциально могли приводить к получению контроля над исполнением систем (в том числе виртуальных машин), работающих на базе определенных CPU. Об этом можно прочитать у нас, например, тут и тут.

При обнаружении таких уязвимостей Intel выпускает обновления микрокода (firmware) для своих процессоров, которые нужно применить как к серверам ESXi, так и к виртуальным машинам. Например, для устранения уязвимости типа MDS была добавлена инструкция MD_CLEAR, которую гостевая ОС может обнаружить и использовать для защиты от определенных уязвимостей.

В виртуальной среде виртуальная машина - это VMX-процесс на сервере ESXi, который обеспечивает исполнение гостевой операционной системы. При этом ВМ может перемещаться между серверами ESXi средствами vMotion, поэтому она может иметь довольно большой аптайм (больше самих хостов, где она работает) и, как следствие, долго не обновлять виртуальное аппаратное обеспечение.

В то же время, для патчинга некоторых уязвимостей нужно обновить микрокод CPU и пересоздать VMX-процесс виртуальной машины, чтобы она могла инициализировать и подхватить обновления микрокода (что происходит только при первой загрузке). Простая перезагрузка тут не поможет, так как в этом случае пересоздания VMX не происходит, а лишь идет ребут гостевой системы. Кстати, это вам на заметку - если хотите "почистить" виртуальную машину, то лучше выключить и включить ее, а не перезагружать.

Чтобы выполнить процедуру выключения и включения, начиная с vSphere 6.5 Update 3 и vSphere 6.7 Update 3, компания VMware ввела инструкцию vmx.reboot.PowerCycle, которая выполняет цикл питания виртуальной машины. Этот параметр, который можно добавить в VMX-файл, считывается со стороны VMware Tools, которые уже совместно с хостом ESXi обеспечивают исполнение этого цикла.

Чтобы добавить этот параметр в VMX-файл через PowerCLI, вы можете использовать следующую команду:

New-AdvancedSetting -Entity YOUR_VM_NAME -Name vmx.reboot.PowerCycle -Value TRUE -Confirm:$false

Это же можно сделать и для групп виртуальных машин, например, находящихся в папке Test Group 1:

Get-Folder "Test Group 1" | Get-VM | New-AdvancedSetting -Name vmx.reboot.PowerCycle -Value TRUE -Confirm:$false

Эти команды можно сопроводить принудительным флагом исполнения -Force и контролировать поведение в случае ошибки с помощью -ErrorAction.

После того, как параметр PowerCycle будет выставлен, VMware Tools (вы же помните, что они должны быть установлены) смогут совершить цикл сброса питания для виртуальной машины, а затем сам параметр будет удален из VMX-файла. Также он будет удален автоматически, если вы вручную завершите и снова запустите виртуальную машину.

Для контроля того, что параметр установлен, вы можете посмотреть в vSphere Client, в разделе Configuration Parameters (в самом низу):

Также использование данного параметра может вам помочь в случае кластеров Enhanced vMotion Compatibility (EVC). Такие кластеры требуют от виртуальных машин поддержки единого базового уровня инструкций CPU для обеспечения vMotion между хостами с разным аппаратным обеспечением.

В случае, если у вас где-то поменялось железо на хостах, то нужно выполнить перезапуск цикла питания виртуальных машин, что приведет кластер EVC к единому базовому уровню и позволит избавиться от потенциальных проблем.

На сайте проекта VMware Labs появилось очередное обновление USB Network Native Driver 1.2 - драйвера для сетевых адаптеров серверов, которые подключаются через USB-порт. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. Напомним, что о версии 1.1 данного драйвера мы писали в июне этого года вот тут.

Обновленный USB Network Native Driver 1.2 теперь дополнительно поддерживает следующие устройства:

• Aquantia Multi-Gig (1G/2.5G/5G) USB network adapter (компания Aquantia - это часть Marvell, кстати это также и производитель адаптеров 10GbE NICs в Mac Mini 2018 и новых iMac Pro).
• Поддержка функции Auto Speed/Connection detection для чипсетов RTL8153/RTL8152.

Таким образом, полный список поддерживаемых теперь устройств выглядит так:

Как пишет Вильям Лам, адаптер  USB-based Multi-Gigabit Network Adapter (QNA-UC5G1T) от QNAP теперь полностью поддерживается (он есть в таблице выше), и он может работать на скоростях 1Gbps, 2.5Gbps и 5Gbps. Но на практике USB 3.1 выдает не больше 3Gbps:

Скачать USB Network Native Driver 1.2 можно по этой ссылке.

Это гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины в аренду. Вопрос обеспечения бесперебойной подачи питания в ЦОД стоит не менее остро, чем вопросы пожаротушения или физической безопасности оборудования. В этой статье мы хотим рассказать нашим читателям, как в ЦОД обеспечивается бесперебойная работа оборудования с точки зрения резервирования источников питания...

Мы часто пишем о томах VVols (Virtual Volumes), которые позволяют вынести часть нагрузки по обработке операций с хранилищами на сторону аппаратных устройств (они, конечно же, должны поддерживать эту технологию), что дает пользователям преимущества по сравнению с VMFS. В инфраструктуре VVols массив сам определяет, каким образом решать задачи доступа и организации работы с данными для виртуальных машин, выделяя для их объектов (виртуальные диски и прочее) отдельные логические тома (VVols).

Один из известных производителей, поддерживающих технологию VVols - это компания Pure Storage. Недавно Cody Hosterman написал статью о том, как подключить тома VVols в VMware vSphere через PowerCLI для хранилищ Pure Storage. Коди развивает свой модуль PowerShell, который называется PureStorage.FlashArray.VMware.

Давайте посмотрим, как он работает. Сначала можно почитать о доступных опциях командлета Mount-PfaVvolDatastore, с помощью которого можно сделать монтирование датастора VVol:

Командлет может делать следующее:

• Проверяет, презентован ли protocol endpoint (PE) указанного массива кластеру. Если нет, то с его помощью можно сделать это.
• Ресканирует кластер, чтобы убедиться, что PE виден хостам.
• Монтирует VVol в кластере.
• Возвращает датастор хранилищу.

Пример 1 - имеется прямой доступ к массиву

Соединяемся с vCenter и создаем соединение с FlashArray:

connect-viserver -Server <vCenter FQDN>
$flasharray = new-pfaConnection -endpoint <FlashArray FQDN> -credentials (get-credential) -ignoreCertificateError -nonDefaultArray

В интерфейсе vSphere Client датастор VVol еще не будет смонтирован:

Со стороны Pure Storage protocol endpoint также не подключен:

Запускаем Mount-PfaVvolDatastore:

Mount-PfaVvolDatastore -flasharray $flasharray -cluster (get-cluster <cluster name>) -datastoreName <datastore name>

После этого PE будет подключен к Pure Storage:

А датастор VVol будет смонтирован к кластеру:

Пример 2 - нет доступа к массиву

Значит тут мы полагаем, что администратор хранилищ уже настроил PE, и вам нужно только смонтировать том VVol:

Так как датастор VVol ранее не монтировался, нельзя просто создать array connection (нет доступа к массиву). В этом случае подойдет командлет Get-VasaStorageArray:

Передав в командлет монтирования массив FA-m50, имя кластера и имя датастора, можно смонтировать том VVol:

$vasaArrays = Get-VasaStorageArray
Mount-PfaVvolDatastore -vasaArray $vasaArrays[<desired index>] -cluster (get-cluster <cluster name>) -datastoreName <datastore name>

Если обобщить, то процесс монтирования датастора VVol с самого начала выглядит так:

• Установка модуля PowerShell
• Соединение с массивом
• Соединение с vCenter
• Создание хостовой группы (в случае с iSCSI нужно еще настроить iSCSI-таргеты)
• Зарегистрировать VASA-провайдер
• Смонтировать датастор VVol

Полный сценарий PowerShell приведен ниже:

install-module PureStorage.FlashArray.VMware

$flasharray = new-pfaConnection -endpoint flasharray-m50-1 -credentials (get-credential) -ignoreCertificateError -nonDefaultArray
connect-viserver -Server vcenter-02

$cluster = get-cluster Embarcadaro

New-PfaHostGroupfromVcCluster -cluster $cluster -iscsi -flasharray $flasharray

New-PfaVasaProvider -flasharray $flasharray -credentials (get-credential)

Mount-PfaVvolDatastore -flasharray $flasharray -cluster $cluster -datastoreName m50-VVolDS

А так в консоли vSphere Client:

Это гостевой пост компании ИТ-ГРАД, предоставляющей виртуальные машины из облака в аренду. VMware обновили свой гипервизор ESXi. Теперь скорость работы виртуальных графических процессоров под его управлением сопоставима с возможностями их bare metal реализаций — разница составляет всего 3%. Рассказываем, как компании удалось этого добиться...

На VMware Labs еще одно обновление - инженеры VMware выпустили продукт Flowgate, который представляет собой средство агрегации данных из различных источников. Это middleware, которое позволяет провести агрегацию данных систем инвентаризации датацентров DCIM / CMDB и далее передать их в системы управления задачами инфраструктуры (например, vRealize Operations).

В данном решении есть встроенный адаптер для интеграции со следующими системами DCIM и CMDB, которые хранят данные о составе, размещении и конфигурации ИТ-инфраструктуры:

• Nlyte
• PowerIQ
• Infoblox
• Labsdb
• IBIS (еще не полностью)
• Pulse IoT Center (еще не полностью)

С точки зрения интеграции с этими системами, все происходит в графическом интерфейсе в несколько кликов. Также внутри Flowgate есть встроенный механизм управления пользователями и ролями RBAC (Role Based Access Control) с большим выбором привилегий для конфигурации.

Надо отметить, что архитектура Flowgate открыта для интеграции с любыми другими сторонними системами. С помощью RESTFul API можно запрашивать любые данные и далее визуализовывать их уже как угодно, также все задачи управления решением доступны через API.

С точки зрения систем управления задачами ИТ-инфраструктуры, где собранные метрики визуализируются, на данный момент реализована интеграция с vCenter Server и vRealise Operation Manager, но скоро будет добавлена поддержка и других систем.

Более подробно о том, как работает Flowgate, можно узнать из следующего видео, созданного авторами Flowgate:

Для машины с Flowgate на борту, осуществляющей агрегацию данных, потребуется минимум 4 vCPU, 8 ГБ памяти и 60 ГБ диска, но рекомендуется выделить 8 vCPU и 16 ГБ RAM соответственно.

Скачать Flowgate можно по этой ссылке.

На сайте проекта VMware Labs появилось очередное обновление - стала доступна новая версия средства USB Network Native Driver for ESXi до версии 1.1. Напомним, что ранее мы писали о нем вот тут. Это нативный драйвер для сетевых адаптеров серверов, которые подключаются через USB-порт.

Такой адаптер можно использовать, когда вам необходимо, например, подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. В каких-то еще случаях подключение такого адаптера может помочь, чтобы получить еще одно сетевое соединение без необходимости перезагружать сервер (и так же просто отключить его).

Новая версия драйвера содержит поддержку девяти новых устройств USB NIC, включая девайсы USB 2.0 RTL8152 & TPLINK. Полный список поддерживаемых устройств теперь таков:

Помимо этого, в драйвер также была добавлена поддержка Jumbo Frames (размером до 4K) для устройств RTL8153 и AX88179.

Для установки драйвера нужно развернуть на ESXi 6.5 или 6.7 один из двух VIB-пакетов для соответствующей версии:

• ESXi670-VMKUSB-NIC-FLING-20124247-offline_bundle-11613968
• ESXi650-VMKUSB-NIC-FLING-20123976-offline_bundle-11613344

Делается это следующей командой:

esxcli software vib install -d /path/to/the/offline/bundle

После установки нужно перезагрузить хост VMware ESXi, после чего устройство USB NIC будет автоматически смонтировано как, например, vusb0.

Скачать USB Network Native Driver for ESXi можно по этой ссылке.

Интересный пост Дэвида Пасека про чипсет материнской платы виртуального аппаратного обеспечения виртуальных машин на платформе VMware vSphere. Оказывается, все ВМ, независимо от версии виртуального "железа" (включая Virtual Hardware Version 14 в vSphere 6.7 Update 1), используют одну и ту же виртуальную материнскую плату на базе Intel 440BX, которая в свойствах системы называется "440BX Desktop Reference Platform" (скриншот из гостевой ОС Windows 10):

Примечательно, что этот чипсет был выпущен в апреле 1998 года - в том же году, когда была основана VMware, а через год был выпущен первый продукт компании VMware Workstation. И вот с тех пор чипсет виртуальной материнской платы не менялся! Видимо, незачем вносить туда серьезные изменения, от него ничего особо в работе виртуальной машины не зависит.

Кстати, изнутри гостевой ОС виртуальной машины можно поймать модель материнской платы следующей командой:

Get-WMIObject win32_baseboard | Select-Object Product

Это же позволит вам определить, что, например, ваш сценарий или программа работает в ВМ.

В Linux, возможно, сработает эта команда:

# dmidecode | grep -C 3 'Base Board'

Часто администраторы виртуальной инфраструктуры VMware vSphere и отказоустойчивых кластеров VMware vSAN задаются вопросом, а как найти тот или иной диск vSAN в физическом сервере?

Иногда такую информацию можно получить с помощью следующей команды:

esxcli storage core device physical get -d <device id>

Вывод будет выглядеть следующим образом:

Исполнять эту команду для каждого из дисков достаточно проблематично, особенно учитывая, что нужно еще предварительно получить id устройства.

Также эту информацию можно посмотреть в разделе Cluster > Configure > vSAN > Disk Management, выбрав режим показа дисков "By Disk Vendors":

Но это тоже неудобно, хотелось бы такую информацию получать через PowerCLI. Информацию о дисковых устройствах можно получить с помощью командлета Get-ScsiLun, который выдает адаптер, к которому подключен диск, а также является ли он SSD-устройством, подходит ли для vSAN и другое. Но, к сожалению, он не дает данных об enclosure для этого диска, поэтому дополнительно нужно воспользоваться командлетом Get-EsxCli, который добавит эту информацию.

Таким образом, VMware предлагает использовать вот такой сценарий PowerCLI, который выведет информацию о физических устройствах, их нахождении в enclosure и слоте, а также типе дисков и их емкости:

Сам сценарий доступен по этой ссылке: https://code.vmware.com/samples/5539 (кстати, обратите внимание, что на портале VMware Code можно найти еще много чего интересного).

У компании VMware вышла полезная многим администраторам решения vRealize Operations (vROPs) онлайн-утилита для сайзинга управляющей инфраструктуры - vRealize Operations Sizing Tool. Она будет полезна администраторам и консультантам, которые планируют развертывание инфраструктуры vROPs и подбирают для этого оборудование и необходимые мощности.

В случае прикидочного расчета нужно просто выбрать версию vRealize Operations Manager и указать тип сайзинга Basic:

Это даст обобщенные требования к оборудованию при минимальном вводе данных. В basic-режиме вы просто задаете параметры своей виртуальной инфраструктуры, условия хранения данных на серверах vROPs и планируемый рост инфраструктуры:

Также параметр High Availability удвоит число необходимых узлов за счет введения резервных.

Итогом будут рекомендации по числу и конфигурации узлов, которые будут обслуживать сервисы мониторинга vROPs (для этого надо нажать на ссылку View Recommendations):

Полученный отчет можно выгрузить в PDF-формат. Кстати, если нажмете на вкладку Environment, то можно будет скорректировать данные, не начиная процесс с начала.

Если же вы выберете режим Advanced для более точного сайзинга, то в самом начале у вас запросят несколько больше данных о вашей виртуальной инфраструктуре:

После параметров объектов vCenter вы сможете задать имеющиеся или планируемые Management Packs от сторонних производителей или самой VMware (и число отслеживаемых объектов в них):

Если же у вас уже есть инфраструктура vRealize Operations, то vRealize Operations Sizing Tool - это хорошее средство, чтобы проверить, что вы правильно подобрали конфигурацию узлов под vROPs.

Для этого надо пойти в раздел Administration > History > Audit > System Audit и там посмотреть итоговое настроенное число объектов (Objects) и метрик (Metrics):

После этого вы можете вбить это число в разделе Other Data Sources и получить расчет параметров сервера, который более-менее должен сходиться с вашей конфигурацией узлов:

Многие из вас знают, что у компании StarWind есть продукт Virtual SAN для построения программных отказоустойчивых хранилищ, являющийся на сегодняшний день одним из лидеров отрасли. Но самое интересное, что у StarWind есть и программно-аппаратный комплекс HyperConverged Appliance (HCA), на базе которого можно строить недорогую инфраструктуру виртуализации и хранения для небольших компаний (а также для сценариев ROBO - remote or brunch offices, то есть филиалов).

На сайте проекта VMware Labs обновилась полезная утилита для проверки соответствия хостов ESXi требованиям списка совместимости для узлов кластера vSAN. Недавно мы писали об улучшении онлайн-средства для поиска поддержки технологии VVols, а на днях обновилась также и утилита vSAN HCL Checker до версии 2.0. Напомним, что о прошлой версии этого решения мы писали вот тут.

Что нового в версии vSAN Hardware Compatibility List Checker 2.0:

• Добавлено 3 новых проверки:
  • Добавлена информация о контроллерах, которые сертифицированы VMware для нужного релиза ESXi.
  • Информация о драйверах контролеров, сертифицированных VMware.
  • Информация о микрокоде (firmware), сертифицированном VMware.
• Обновленный формат HTML-отчета.
• Несколько исправлений ошибок.

Для начала работы нужно просто ввести имя хоста ESXi и пароль пользователя root:

В качестве результата в папке с утилитой будет сформирован html-файл (этот шаблон можно редактировать в файле reportTemplate.html), в котором будет информация о совместимости контроллеров хранилищ со списком VSAN HCL (шильдики yes и N/A).

Загрузить vSAN Hardware Compatibility List Checker 2.0 можно по этой ссылке.

P.S. Если у вас проблемы с использованием утилиты, попробуйте опцию --noSSLVerify.

Компания VMware, прислушавшись к фидбэку пользователей, сделала несколько улучшений в онлайн-утилите VMware Compatibility Guide в плане поиска поддержки VVols (кстати, почитайте нашу статью о политиках SPBM на томах VVols).

Теперь новый VCG позволяет получить ответы на следующие вопросы:

• Какой дисковый массив поддерживает технологию VVols?
• Какую версию ESXi поддерживает тот или иной вендор оборудования?
• Какая есть сертификация VASA?
• Какие возможности VVols поддерживает устройство?
• Какие проблемы или ограничения имее реализация VASA Provider на устройстве?

Кликнув на производителя (Partner Name), вы увидите какие типы VASA Provider он поддерживает и на каких моделях дисковых массивов.

Также, выбрав нужную вам фичу VVols, например, VVols Storage Replication, вы можете вывести всех производителей, кто ее поддерживает:

Раскрыв категорию Partner Name для нужного производителя, вы увидите какие версии ESXi какие функции поддерживают:

Обратите внимание, что справа в таблице есть ссылка "VASA Provider Download", которая позволяет вам загрузить актуальную версию компонента-провайдера интерфейса VASA.

Также есть еще один полезный раздел, который открывается по клику на "Click here for more Details":

Тут уже можно найти детальную информацию о поддерживаемых протоколах, статьях базы знаний (KB), версии VASA provider и VASA VVol Spec, а также многое другое.

Как вы знаете, в VMware vSphere 6.7 Update 1 средство обновления vSphere Update Manager (VUM) получило множество новых возможностей, в том числе функцию обновления микрокода (firmware) I/O-адаптеров серверов, входящих в состав кластера vSAN. Эта функциональность как раз перекочевала туда из интерфейса vSAN (называлось это раньше Configuration Assist).

VUM использует утилиту обновления драйверов от вендора оборудования (сервера). Таким образом, обновление драйвера I/O-устройства (HBA-адаптера) можно включить в двухступенчатый цикл обновления хоста и не заниматься этим отдельно, что уменьшает общее время обновления.

Если VUM не нашел утилиты обновления от вендора, он предлагает загрузить ее. Для этого он анализирует Release Catalog, учитывая информацию из HCL (Hardware Compatibility List). При этом поддерживаются и кастомные ISO-образы от OEM-производителей (версия билда ESXi также распознается).

Когда вы зайдете в Host Updates в VUM, вы увидите вот такое сообщение:

Firmware engine needs to download hardware vendor’s firmware tool to vCenter.

Если вы нажмете "Download vendor firmware tool", то увидите, что для загрузки утилиты обновления микрокода можно использовать как дефолтный, так и свой репозиторий:

Как это известно по ситуации с драйверами Windows, установщик не найдет нужный драйвер, поэтому, скорее всего, придется указать свой путь к утилите обновления, например для контроллера Dell PERC путь может выглядеть как-то так:

http://downloads.dell.com/FOLDER03037799M/1/vmware-esx-perccli-1.05.08.zip

Обратите внимание, что по кнопке Browse можно указать свой файл, если у вас нет подключения к интернету:

Кстати, проверки состояния vSAN health checks интегрированы с рабочими процессами Update Manager, что позволяет приостановить процесс обновления хостов кластера в случае, если после обновление с одним из них пошло что-то не так. Также есть возможность загрузить на сервер vCenter файл HCL-манифеста в формате JSON, чтобы указать соответствия билдов ESXi и оборудования, если вы обновляетесь через VUM в офлайн-режиме.

Сегодня Алексей расскажет про две тонкости с которыми пришлось повозиться на следующем этапе установки – обе относятся к подготовке образа для установки.

Первая – выбор места для установки. Если в вашем сервере на момент загрузки присутствует один диск, и вы планируете его использовать для установки, то проблем нет. А если их несколько, и вам нужно использовать какой-то определенный, то придется указать на желаемый диск с помощью команды:

install --disk=diskname или install –-firstdisk=disk-type

что и прекрасно описано в документации здесь: https://kb.vmware.com/s/article/2004582.

В моем же случае в системе имелся маленький SSD (так называемый BOSS card, в случае Dell – RAID1 массив из двух SATA m.2 SSD) для установки системы и большой RAID-массив, на котором теоретически могли располагаться виртуальные машины (в случае если производится переустановка хоста).

Что в вышеприведенной статье не упомянуто – так это как найти diskname или disk-type для искомого диска/массива.
А сделать это можно следующим образом:

• Проведите тестовую установку в ручном режиме.
• Запустите SSH сервис и подключитесь к серверу по SSH.
• Используйте команду esxcli storage core device list для того, чтобы получить список всех контроллеров в системе.

Искомая информация для вашего контроллера будет в поле Model:

Итоговая команда в моем случае:

install --firstdisk="DELLBOSS VD" --overwritevmfs --novmfsondisk

Вторая тонкость выяснилась, когда я начал тестировать загрузочный диск. Сервер из другой поставки наотрез игнорировал содержимое kickstart файла. Выяснилось что один из серверов был сконфигурирован использовать EFI для загрузки, другой же - классический BIOS. ISO-образ ESXi содержит два различных BOOT.CFG файла для этих двух типов загрузки:

• для BIOS - в корне образа
• для EFI - соответственно, в папке /EFI/BOOT

Если в вашем случае, как и мне, нужно иметь один kickstart файл для обоих типов загрузки, не забудьте отредактировать оба файла.

Надеюсь, это сэкономит кому-то время.

На написание этого поста меня вдохновила достаточно старая, но лично мною обнаруженная совсем недавно статья Романа Гельмана "PowerShell скрипт для автоматической установки ESXi хостов на серверах IBM/Lenovo". Какое-то время назад появилась необходимость автоматизировать процесс развертывания новой инфраструктуры для vSphere для клиента...